InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0012.txt

Text File | 1993-07-02 | 14.1 KB | 277 lines

Chris Newman @ CMU writes:
> IMAP2 is a protocol for remote mailstore access (from what I
> understand).  Anything which isn't "remote mailstore access" should be
> placed in a separate protocol.  The idea of placing a message in a
> mailstore to be "picked up for delivery" seems like a very backwards
> way to do mail submission -- why not contact the transport agent
> directly with an appropriate simple protocol (e.g. SMTP)?

I'm not suggesting that IMAP2 take over the role of SMTP, just that it
provide facilities to (at least) submit the draft messages it manages. If
it doesn't have draft message management, there is less reason to support
submission. However, integrating retrieval and submission may open the way
for extra functions in the future, e.g. marking messages as 'replied-to'.
It's what I'd call an 'enabling step' if I was asking my boss to fund it.

A lot of people think that 'remote mailstore access' these days means
far more than just retrieval. X.400 P7 is IMHO a good _model_ (and believe
me, I have read the standards), even if details of the implementation are
still flawed. (Half the problem seems to be that people don't understand
ASN.1, which is strange, as it is used in a number of Internet protocols.)

> I'm used to MUAs that generate the envelope from the headers
> automatically

Fine. If an IMAP2-managed draft message is 'ready for sending', without
user intervention, it makes even less sense to _require_ the MUA to fetch
it and submit it.

> But then a mailstore isn't suitable for storing of an envelope --
> only for storage of RFC-822 and MIME messages.

Why Internet only? My 'mailstore' contains messages from X.400, BITNET,
Internet and Greybook hosts. The fact that they are all converted to one
format (Greybook) is something that I, as a user, don't need to be aware
of. Concrete example: we are looking at providing IMAP2 access to an X.400
message store.

I think at least one non-contentious point has come out of this discussion
though: that (a) central draft message management is often necessary, and
(b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is
ideal for draft message management. Would it be possible to have 'DRAFT'
and 'SENT' system flags, to be modified only by the IMAP2 server?
From [e-mail]  Fri Sep  4 09:58:06 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA17975; Fri, 4 Sep 92 09:58:06 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA01819; Fri, 4 Sep 92 09:58:00 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA01813; Fri, 4 Sep 92 09:57:58 -0700
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA13884> for [e-mail]; Fri, 4 Sep 92 12:57:44 EDT
Received: via switchmail; Fri,  4 Sep 1992 12:57:42 -0400 (EDT)
Received: from nifty.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.oedtIci00WA786B05s>;
          Fri,  4 Sep 1992 12:56:09 -0400 (EDT)
Received: via niftymail; Fri, 4 Sep 1992 12:56:05 -0400 (EDT)
Date: Fri, 4 Sep 1992 12:56:02 -0400 (EDT)
From: Chris Newman <[e-mail]>
Subject: re: IMAP2 futures?
To: A Grant <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>

In message <[e-mail]>,
 A Grant <[e-mail]> writes:
>Chris Newman @ CMU writes:
>I'm not suggesting that IMAP2 take over the role of SMTP, just that it
>provide facilities to (at least) submit the draft messages it manages.

Ok, suppose I actually wanted to implement some sort of submission via
IMAP.  There are a few ways to do this:

1) Put part or all of the mail transport agent (MTA) in the IMAP server.
This is clearly a *bad thing* as it makes IMAP many times more
complex, and makes it less portable (particularly to places where
"standard" mail transport systems aren't used).

2) Have the IMAP server contact the MTA and submit the message itself.
This causes the IMAP server to have an external dependancy on another
machine/service.  At CMU, we've found this to be a *very bad thing*.
Our system has so many inter-dependancies that if one thing goes down,
it usually takes the whole system with it.  Our current design goal
for replacement systems it to have each service as independant as
possible.

3) Have the MTA pick up the message directly from the mailstore.  This
requires the MTA to understand the mailstore format(s) and to run on
the IMAP server.  So this is a *bad thing* as it makes the MTA more
complex (and less portable), and makes the IMAP server harder to
manage and maintain (particularly at large sites with multiple
servers).

4) Have the MTA pick up the messages via IMAP.  This requires the MTA
to understand IMAP protocol, have a dependancy on the IMAP server, and
is probably less efficient than sending the message directly to the
MTA from the client.  So this is also a *bad thing*.

I can't think of any other ways to implement submission via IMAP, and
all of these are bad solutions.  Since the client needs to understand
whatever mail submission protocol (e.g. SMTP) is used anyway, it's
best to keep the server simple (as Mark advocates).  The tiny cost of
fetching a draft message from the server for submission by the client
is nothing compared to the damage that adding submission to the IMAP
server would cause the protocol's simplicity, portability, and
manageability.

>If it doesn't have draft message management, there is less reason to support
>submission. However, integrating retrieval and submission may open the way
>for extra functions in the future, e.g. marking messages as 'replied-to'.
>It's what I'd call an 'enabling step' if I was asking my boss to fund it.

IMAP already has facilities for flag management in a mailstore.  A
client which wants such bells and whistles merely needs to set the
flags in the server after it submits the mail.  There's no need to
"integrate" retrieval and submission to get such features.

>I think at least one non-contentious point has come out of this discussion
>though: that (a) central draft message management is often necessary, and
>(b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is
>ideal for draft message management. Would it be possible to have 'DRAFT'
>and 'SENT' system flags, to be modified only by the IMAP2 server?

I would classify draft management as a "nice" feature.  Something
worth doing only if the implementation is trivial.  If draft
management can be done using APPEND (and perhaps the existing IMAP
flag support), it's worth doing, otherwise I'd prefer keeping the
server simple.

        - Chris
        Computing Services, Carnegie Mellon University
From [e-mail]  Fri Sep  4 10:43:26 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA19412; Fri, 4 Sep 92 10:43:26 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA02429; Fri, 4 Sep 92 10:43:22 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA02419; Fri, 4 Sep 92 10:43:20 -0700
Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk
          with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <[e-mail]>;
          Fri, 4 Sep 1992 18:42:35 +0100
Date: Fri, 04 Sep 92 18:42:25 BST
From: A Grant <[e-mail]>
To: [e-mail]
Subject: Draft messages etc. (was IMAP2 futures)
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>

> The tiny cost of
> fetching a draft message from the server for submission by the client
> is nothing compared to the damage that adding submission to the IMAP
> server would cause the protocol's simplicity, portability, and
> manageability.

As an Australian working in the UK I know that data traffic does not come
for free. I can see myself doing IMAP2 from Oz and wanting to forward the
messages in my inbox to UK colleagues, based on contents of header fields.
Retrieving 10Mb MIME video messages from half way round the world and
sending them back again would be gross!

I am not convinced the 'damage' is significant. Good application-layer
protocols are extensible and modular. If IMAP2 is so hairy that adding an
optional submission 'subset' to it involves major surgery, I'm not sure it
has a future. Thankfully, I think it _is_ able to be extended nicely.

I see that you (implicitly) accept that there may be a need for IMAP2 to
manage draft messages. We can't be the only potential IMAP2 users who see
transparent distributed file systems as a long way off.

Maybe I'm overestimating the problem. I'd really appreciate it if anyone
who's using IMAP2 in a large-scale heterogenous environment could share
their experiences.
From [e-mail]  Fri Sep  4 10:51:45 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA19637; Fri, 4 Sep 92 10:51:45 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA02533; Fri, 4 Sep 92 10:51:41 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from nexus.yorku.ca by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA02527; Fri, 4 Sep 92 10:51:39 -0700
Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9217>; Fri, 4 Sep 1992 13:51:27 -0400
To: A Grant <[e-mail]>
To: [e-mail]
Subject: Re: Draft messages etc. (was IMAP2 futures)
In-Reply-To: Your message of "Fri, 04 Sep 92 13:42:25 EDT."
             <[e-mail]>
Date:     Fri, 4 Sep 1992 13:51:19 -0400
From: [e-mail]
Message-Id: <[e-mail]>

  **Any** protocol get hairy when it tries to deal with
any two distinct kind of things.
  SMTP has a serious problem because of the different time-behavior
of HELO/RCPT/MAIL/VRFY versus DATA: DATA takes variable and unbounded time.
The others take fixed and mutually-predictable times.

  As a result even simple things get arbitrarily hard easily.
(My hack is to read the data part line by line, with timeouts,
and make sure every message uses a **separate process**. Otherwise
I can lock up all of mail waiting for a single ill-structured message)

--dave
From [e-mail]  Fri Sep  4 12:20:06 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA22019; Fri, 4 Sep 92 12:20:06 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA03396; Fri, 4 Sep 92 12:19:55 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA03390; Fri, 4 Sep 92 12:19:48 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
    (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00915; Fri, 4 Sep 92 12:19:42 PDT
Date: Fri, 4 Sep 1992 11:57:59 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Subject: re: Draft messages etc. (was IMAP2 futures)
To: A Grant <[e-mail]>
Cc: IMAP Interest List <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I probably have more experience with international IMAP (and IMAP over slow
speed links -- I'm on a SLIP line from my NeXT at home right now) than anyone
else.

I certainly don't want my drafts sent over the SLIP link to the IMAP server.
I have a perfectly good local filesystem for my drafts.  Nor do I even want my
outgoing mail going to the IMAP server.  I have a perfectly good mailer daemon
on my machine that can do this pain and suffering in the background.  I
especially don't want my outgoing mail making two international hops when I am
sending domestic mail, just because I happen to be talking to a foreign IMAP
server.

I'd undoubtably feel differently if my primary machine was my Mac (or a PC)
instead of my NeXT.  I trust the Mac filesystem much less than the NeXT, and
background mailers on a Mac are still more fantasy than reality.  Yet, even on
the Mac, some of these principles apply.  I want my outgoing mail going to a
domestic machine regardless of whether or not I am talking to a foreign IMAP
server.

That's part of the problem -- different individuals in different environments
have different needs.  How do we solve the needs of one group without causing
trouble to other individuals?

The problem with adding an `optional submission subset' to IMAP is:
 . it will make IMAP hairy -- we seek to avoid this
 . it will create applications which *only* use the `optional' submission
   mechanism.  This is a REAL threat -- the POP world is already filled with
   POP applications which DO NOT WORK unless the POP server supports the
   unofficial and undocumented `optional' submission mechanism of Berkeley
   popper.

The bottom line is: `simple solutions' usually create new problems.  We're not
telling you "no, you can't do what you want"; we're telling you "no, your
proposed solution is not the right one."  We agree with all your stated needs
completely.  It just doesn't belong in IMAP.

On the other hand, it is undoubtably related to IMAP, and belongs as part of a
sister protocol to IMAP.  We have already identified Mail Management as one
sister protocol.  I think that authenticated transport is probably going to be
part of a different sister.  Let's start thinking about these siblings and not
allow IMAP's focus to be blurred.

By the way, I think that a good deal of the problem with the 10MB MIME video
message forwarding can be solved by appropriate use of external-data in MIME.
It seems that people have realized that sending a 1000 person mailing list a
10MB video image, as opposed to a pointer, doesn't scale too well...  ;-)  So
I don't think that example will come up in reality.